fix(discovery-index): bound TtlCache by a max-entry cap enforced on set - #10145

• nit: evictForCapacity's expiry sweep is O(n) over the whole map on every capacity-triggered set once the cache is full, so under sustained new-key churn at the cap this runs a full scan per insert — cache.ts:44-49 — worth a comment noting this is an accepted tradeoff given the cache's stated small/cheap-to-recompute entries, or consider capping the sweep.
• nit: the server.ts wiring test (cache.test.ts:139-150) asserts via regex/string-matching against source text rather than actual TS type-checking, so it can't catch a construction site that's syntactically well-formed but semantically wrong (e.g. passing the cap as the wrong constructor argument) — acceptable given server.ts's stated untestable-entrypoint status, but worth noting as a weaker guarantee than a real import-based test.
• Consider documenting the O(n) sweep tradeoff in evictForCapacity directly (cache.ts:44) since it's the one place performance could matter if entry volume grows well past 5,000.
• The three server.ts call sites (server.ts:29-32) could default to DEFAULT_CACHE_MAX_ENTRIES implicitly instead of being passed explicitly, but explicit is arguably clearer here and matches the PR's intent to make the cap visible at each site — no change needed.

Addressed
TtlCache now takes a maxEntries cap with an exported DEFAULT_CACHE_MAX_ENTRIES default, enforces it in set() by first dropping expired entries then evicting oldest-inserted via Map insertion order (no timers), and server.ts passes the cap explicitly at all three construction sites without changing SoftClaimStore's signature or TTL values.

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 119 PR(s), 3 issue(s).
• PR-specific overlap: none found.

• Start here: Add validation command/output.

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.